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Hypertext Transfer Protocol -- HTTP/1.1 

Status of this Memo 

This document specifies an Internet standards track protocol for the 
Internet communityj and requests discussion and suggestions for 
improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 

Copyright Notice 

Copyright (C) The Internet Society (1999). All Rights Reserved. 
Abstract 

The Hypertext Transfer Protocol (HTTP) is an application-level 
protocol for distributed^ collaborative^ hypermedia information 
systems. It is a generic^ stateless^ protocol which can be used for 
many tasks beyond its use for hypertext^ such as name servers and 
distributed object management systems^ through extension of its 
request methods^ error codes and headers [47] . A feature of HTTP is 
the typing and negotiation of data representationj allowing systems 
to be built independently of the data being transferred. 

HTTP has been in use by the World-Wide Web global information 
initiative since 1990. This specification defines the protocol 
referred to as "HTTP/1. l"j and is an update to RFC 2068 [33]. 
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1 Introduction 
1.1 Purpose 

The Hypertext Transfer Protocol (HTTP) is an application-level 
protocol for distributed^ collaborative^ hypermedia information 
systems. HTTP has been in use by the World-Wide Web global 
information initiative since 1990. The first version of HTTPj 
referred to as HTTP/0. 9j was a simple protocol for raw data transfer 
across the Internet. HTTP/1. 0j as defined by RFC 1945 [6]j improved 
the protocol by allowing messages to be in the format of MIME-like 
messages^ containing metainformation about the data transferred and 
modifiers on the request/response semantics. However^ HTTP/1.0 does 
not sufficiently take into consideration the effects of hierarchical 
proxieSj cachings the need for persistent connections^ or virtual 
hosts. In addition^ the proliferation of incompletely-implemented 
applications calling themselves "HTTP/1.0" has necessitated a 
protocol version change in order for two communicating applications 
to determine each other's true capabilities. 

This specification defines the protocol referred to as "HTTP/1.1". 
This protocol includes more stringent requirements than HTTP/1.0 in 
order to ensure reliable implementation of its features. 

Practical information systems require more functionality than simple 
retrievalj including search^ front-end update^ and annotation. HTTP 
allows an open-ended set of methods and headers that indicate the 
purpose of a request [47]. It builds on the discipline of reference 
provided by the Uniform Resource Identifier (URI) [3]j as a location 
(URL) [4] or name (URN) [20]j for indicating the resource to which a 
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inbound/out bound 

Inbound and outbound refer to the request and response paths for 
messages: "inbound" means "traveling toward the origin server" j 
and "outbound" means "traveling toward the user agent" 

1.4 Overall Operation 

The HTTP protocol is a request/response protocol. A client sends a 
request to the server in the form of a request method^ URIj and 
protocol version^ followed by a MIME-like message containing request 
modifiers^ client informationj and possible body content over a 
connection with a server. The server responds with a status line^ 
including the message's protocol version and a success or error code^ 
followed by a MIME-like message containing server information^ entity 
metainformationj and possible entity-body content. The relationship 
between HTTP and MIME is described in appendix 19.4. 

Most HTTP communication is initiated by a user agent and consists of 
a request to be applied to a resource on some origin server. In the 
simplest case^ this may be accomplished via a single connection (v) 
between the user agent (DA) and the origin server (0). 

request chain > 

UA V 0 

< response chain 

A more complicated situation occurs when one or more intermediaries 
are present in the request/response chain. There are three common 
forms of intermediary: proxy^ gateway^ and tunnel. A proxy is a 
forwarding agents receiving requests for a URI in its absolute form^ 
rewriting all or part of the message^ and forwarding the reformatted 
request toward the server identified by the URI. A gateway is a 
receiving agents acting as a layer above some other server(s) andj if 
necessary^ translating the requests to the underlying server's 
protocol. A tunnel acts as a relay point between two connections 
without changing the messages; tunnels are used when the 
communication needs to pass through an intermediary (such as a 
firewall) even when the intermediary cannot understand the contents 
of the messages. 


request chain > 

UA V A V B V C V 0 

< response chain 


The figure above shows three intermediaries (A, Bj and C) between the 
user agent and origin server. A request or response message that 
travels the whole chain will pass through four separate connections. 
This distinction is important because some HTTP communication options 
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may apply only to the connection with the nearest^ non-tunnel 
neighboTj only to the end-points of the chain^ or to all connections 
along the chain. Although the diagram is linear^ each participant may 
be engaged in multiple^ simultaneous communications. For example^ B 
may be receiving requests from many clients other than A, and/or 
forwarding requests to servers other than C, at the same time that it 
is handling A's request. 

Any party to the communication which is not acting as a tunnel may 
employ an internal cache for handling requests. The effect of a cache 
is that the request/response chain is shortened if one of the 
participants along the chain has a cached response applicable to that 
request. The following illustrates the resulting chain if B has a 
cached copy of an earlier response from 0 (via C) for a request which 
has not been cached by DA or A. 


request chain > 

UA V A V B------C------0 

< response chain 


Not all responses are usefully cacheable^ and some requests may 
contain modifiers which place special requirements on cache behavior. 
HTTP requirements for cache behavior and cacheable responses are 
defined in section 13. 


In factj there are a wide variety of architectures and configurations 
of caches and proxies currently being experimented with or deployed 
across the World Wide Web. These systems include national hierarchies 
of proxy caches to save transoceanic bandwidth^ systems that 
broadcast or multicast cache entries^ organizations that distribute 
subsets of cached data via CD-ROM^ and so on. HTTP systems are used 
in corporate intranets over high-bandwidth linkSj and for access via 
PDAs with low-power radio links and intermittent connectivity. The 
goal of HTTP/1.1 is to support the wide diversity of configurations 
already deployed while introducing protocol constructs that meet the 
needs of those who build web applications that require high 
reliability andj failing thatj at least reliable indications of 
failure . 


HTTP communication usually takes place over TCP/IP connections. The 
default port is TCP 80 [19] j but other ports can be used. This does 
not preclude HTTP from being implemented on top of any other protocol 
on the Internet^ or on other networks. HTTP only presumes a reliable 
transport; any protocol that provides such guarantees can be used; 
the mapping of the HTTP/1.1 request and response structures onto the 
transport data units of the protocol in question is outside the scope 
of this specification. 
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